Post not yet marked as solved
Yes. As I said, manually from the dock the app is allowed to create multiples scenes. When I do that programmatically it doesn’t work.
Turns out the host app requires a special entitlement key (com.apple.security.temporary-exception.audio-unit-host) that has to be then authorized during the app review.
Hi, thanks for the reply.
Unfortunately the documentation of scheduleMIDIEventBlock and scheduleMIDIEventBlock is quite sparse and no concrete examples around.
I think the AVAudioEngine solution would fit better to my needs, since the my standalone app already uses this class and a Mixer as a multi-instrument, multi-effect rack. Where I get lost is how to implement the same infrastructure as an Audio Unit.
In createAudioUnit(with componentDescription: AudioComponentDescription) of AudioUnitViewController, passing the mixer AUAudioUnit doesn't seem enough and, second, what about the MIDI connection between the host app and the first input unit of the mixer?
I'd appreciate if someone could point me in the right direction.
Post not yet marked as solved
In my case it happens when I create a new persistent container, deallocating the old one. It seems that the CloudKit mirroring remains alive, then after few seconds it raises the exception.
No issues in iOS 13.x with same code.
A possibile workaround is to remove the store(s) from the old container, before deallocating it. At that point I have the following log message: "<NSCloudKitMirroringDelegate>: Told to tear down because the store has been removed.". The problem is that this "hack" raises other kind of issues for my app's logic, like UI notifications, so for me is a no go.
Post marked as Apple Recommended
Same problem here. No documentation provided on how to use NSPersistentCloudKitContainerEvent.
Post not yet marked as solved
Stuck since June with 3 serious issues on iOS 14, not present in iOS 13. If iOS 14 will be released as it is, we’ll have to retire the app from the store due to compatibility issues, and our help desk will be flooded by messages of angry users.
At every beta we update the feedbacks with the usual, and I suspect useless, “Still present in beta x”.
If they only allowed to share feedbacks, it would be easier to group identical issues and lighten their work.
Ken is right on “And while the numbers of devs have increased dramatically, I doubt the number of human engineers slaving over raw reports has kept pace, most likely supported by an increase AI”, but frankly and egoistically I’d say “Who cares how you do it? Where’s the support I deserve as a developer on your platform?”
Welcome to the App Store (I’m publishing on it since 2009 and the problems are the same, just take it or leave it).
Post not yet marked as solved
Stuck since June with 3 serious issues on iOS 14, not present in iOS 13. If iOS 14 will be released as it is, we’ll have to retire the app from the store due to compatibility issues, and our help desk will be flooded by messages of angry users.
At every beta we update the feedbacks with the usual, and I suspect useless, “Still present in beta x”.
If they only allowed to share feedbacks, it would be easier to group identical issues and lighten their work. Welcome to the App Store (I’m publishing on it since 2009 and the problems are the same, just take it or leave).
Post not yet marked as solved
Yes you can. Just use an UIHostingController as your plugin view controller.
Post not yet marked as solved
Thanks for your reply.Tried but still not working. It does work disabling the sandbox but, of course, no App Store.
Post not yet marked as solved
HiI'm working also on a plug-in host and, as you this is old post you've been into this. I'm not able to open third party plug-ins. Any success on this?
